1. Field of the Invention
The present invention relates to a congestion control in a communications network, and more particularly to a congestion control in a communications network using a frame relay method.
Nowadays, packet communications networks which conform with the ITU-T X. 25 standard have been reduced to practice. At nodes provided in a package communications network, packets are assembled from data from terminal equipment and are sent to communications paths. Further, at the nodes, packets received from the communications paths are disassembled and sent to the terminal equipment. At each node, a confirmation process is carried out in which it is determined whether or not a packet has duly been received. When it is confirmed that the packet has duly been received, the packet is sent to the next node.
2. Description of the Prior Art
Recently, a frame relay method has been proposed with improvements in the quality of transmission paths such as optical fibers (see Q.922 and Q.933 of the ITU-T Recommendations, the disclosure of which is hereby incorporated by reference). In a network using the frame relay method, each node simply sends the received packet to the next node without any modification. That is, each node does not determine whether or not the packets have duly been received, except for a frame check sequence (FCS). The checking process for determining whether or not the packets have duly been received is carried out by the terminal equipment which receives the packets. With the above method, it becomes possible to reduce the time it takes to transmit the packets.
When actually constructing a network, it is necessary to consider a congestion taking place in the network. More particularly, it is necessary to predetermine processes for coping with faults in the network and the resource limitations of the terminal equipment. In the packet communications networks conforming with the ITU-T X. 25 standard, each node provided therein performs the check operation. Hence, each node can easily cope with congestions occurring in the network. In this case, the node which detects a congestion sends the terminal equipment a predetermined indication indicating that packets cannot be received. The ITU-T X. 25 standard defines the above indication as an RNR (Receive Not Ready) frame signal. The terminal equipment which receives the RNR frame stops sending packets and/or limits the amount of information to be sent. When the congestion or fault has been removed, a signal indicating the above is sent to the terminal equipment. The ITU-T X. 25 standard defines the above signal as an RR (Receive Ready) signal.
The network using the frame relay network operates in a way different from that of the ITU-T X. 25 standard network. In the network using the frame relay network, each node sends the received packets to the next node without any modification. Hence, it is necessary to cope with the congestions and faults in a way different from that in the ITU-T X. 25 standard network. Regarding the congestions, the Q. 922 and Q.933 of the ITU-T Recommendations define the following ways. When a congestion occurs in the network, a congestion notification bit notifying the terminal equipment of the occurrence of the congestion is turned ON (for example, switched to "1"). The terminal equipment which receives the congestion notification bit in the ON state knows that the congestion occurs in the network and executes a predetermined congestion control process. For example, the terminal equipment stops sending information and limits the amount of information to be sent. According to the ITU-T Recommendations, an FECN (Forward Explicit Congestion Notification: congestion notification in the forward direction) bit and a BECN (Backward Explicit Congestion Notification: congestion notification in the backward direction) bit are defined as the above congestion notification bit. When the network is recovered from the congestion, the network turns OFF congestion recovery notification information and sends it to the terminal equipment.
By the way, there is a case where a packet terminal (a terminal conforming with the ITU-T X. 25 standard) is connected to a network using the frame relay method (hereinafter such a network is referred to as a frame-relay network). For example, such a case will occur by connecting a packet terminal conventionally used to a frame-relay network newly constructed. In this case, a terminal adapter is provided between the packet terminal and the frame-relay network in order to absorb the difference between the X. 25-based frame format (LAPD: Link Access Procedure on the D-channel) and the frame format based on the frame relay method (LAPF: Link Access Procedure for Frame mode bearer service). In other words, the terminal adapter has the function of interchanging the different formats with each other.
In this case, if the frame-relay network is congested, the terminal adapter sends the terminal adapter and a frame-relay terminal a frame in which the above-mentioned FECN or BECN is ON. The frame-relay terminal is a terminal that conforms with the frame network method. The terminal adapter which receives the above frame performs a process in which information transferred in the LAPF format is placed in the LAPD format or the LAPD format capsuled in the LAPF format is extracted.
However, the packet terminal accommodated in the frame-relay network via the terminal adapter cannot know the occurrence of a congestion in the frame-relay network. This is because the congestion notification bit is not included in the LAPD format. Similarly, the packet terminal cannot know the recovery of the congestion.